Search for: All records

Refactoring a large and complex class can be challenging, not only because the class aggregates many different responsibilities but also because of its potentially extensive impact on external classes. Although many extract class methods have been proposed, few support a holistic decomposition that can uncover multiple distinct responsibilities within a complex class, along with their system-wide impacts. Recent research highlights the need for such a holistic view before an organization can commit to redesigning and refactoring. To identify distinct responsibilities while minimizing internal and external impacts, we created Deicide, a new decomposition algorithm that uses an internal call graph, external usage patterns, and semantic similarity of identifiers to calculate a hierarchical set of cohesive clusters, each forming a responsibility module. We evaluated Deicide against three state-of-the-art extract class recommenders using 123 large, change-prone classes from 9 open-source projects. Our results show that the entities within the clusters identified by Deicide are more likely to be changed together and changed by the same group of developers, indicating de facto cohesive responsibilities. The implication is that refactoring based on Deicide’s recommendations would have minimal impact on the system, and these newly extracted classes would be able to evolve independently. 

Complex software systems consist of multiple overlapping design structures, such as abstractions, features, crosscutting concerns, or patterns. This is similar to how a human body has multiple interacting subsystems, such as respiratory, digestive, or circulatory. Unlike in the medical domain, software designers do not have an effective way to distinguish, visualize, comprehend, and analyze these interleaving design structures. As a result, developers often struggle through the maze of source code. In this paper, we present an Automated Concept Explanation (ACE) framework that automatically extracts and categorizes major concepts from source code based on the roles that files play in design structures and their topic frequencies. Based on these categorized concepts, ACE recovers four categories of high-level design models using different algorithms and generates a natural language explanation for each. To assess if and how ACE can help developers better understand design structures, we conducted an empirical study where two groups of graduate students were assigned three design comprehension tasks: identifying feature-related files, identifying dependencies among features, and identifying design patterns used, in an open-source project. The results reveal that the students who used ACE can accomplish these tasks much faster and more accurately, and they acknowledged the usefulness of the categorized concepts and structures, multi-type high-level model visualization, and natural language explanations. 

Background: Software practitioners need reliable metrics to monitor software evolution, compare projects, and understand modularity variations. This is crucial for assessing architectural improvement or decay. Existing popular metrics offer little help, especially in systems with implicitly connected but seemingly isolated files. Aim: Our objective is to explore why and how state-of-the-art modularity measures fail to serve as effective metrics and to devise a new metric that more accurately captures complexity changes and is less distorted by sizes or isolated files. Methods: We analyzed metric scores for 1,220 releases across 37 projects to identify the root causes of their shortcomings. This led to the creation of M-score, a new software modularity metric that combines the strengths of existing metrics while addressing their flaws. M-score rewards small, independent modules, penalizes increased coupling, and treats isolated modules and files consistently. Results: Our evaluation revealed that M-score outperformed other modularity metrics in terms of stability, particularly with respect to isolated files, because it captures coupling density and module independence. It also correlated well with maintenance effort, as indicated by historical maintainability measures, meaning that the higher the M-score, the more likely maintenance tasks can be accomplished independently and in parallel. Conclusions: Our research identifies the shortcomings of current metrics in accurately depicting software complexity and proposes M-score, a new metric with superior stability and better reflection of complexity and maintenance effort, making it a promising metric for software architectural assessments, comparison, and monitoring.